Part 12: Tagging and Hierarchy-Based Allocation

Main Idea

How can everyone take accountability for their cloud spend (principle 3) if they can't see what it is.

• Cost allocation becomes useful only when cloud spend can be tied back to clear business ownership.
• The two main allocation mechanisms are hierarchy-based structures and resource-level metadata.
• Mature FinOps teams usually combine both rather than relying on only one.
• The key to winning at FinOps is to get account and tagging strategies established early on and maintain them consistently.

Note:

• Cloud providers use different terms for similar concepts, including tags, labels, accounts, subscriptions, and projects.
• These can all be referred to broadly as metadata, but for simplicity this chapter treats hierarchy structures as accounts and key/value pairs as tags.
• When this chapter says tags, it also includes Google Cloud labels.
• When this chapter says accounts, it also includes Google Cloud projects and folders, as well as Azure subscriptions and resource groups.

Two Core Allocation Approaches

• Hierarchy-based allocation uses cloud-native structures such as AWS accounts, Google Cloud projects or folders, and Azure subscriptions or resource groups.
• Tag-based allocation uses metadata such as tags or labels attached to resources.
• Hierarchies provide strong separation and enforceability, while tags provide finer-grained context.

Why Raw Billing Data Is Not Enough

• Billing data shows what was used, where it ran, and how much it cost.
• What it does not contain by default is business context such as owner, team, product, service, or cost center.
• Allocation structures are what make billing data usable for financial and operational decisions.

Tags Add Business Context

• Tags allow teams to associate cloud resources with business-specific attributes.
• They help answer questions about ownership, accountability, chargeback, and service cost.
• This is what turns technical usage records into meaningful FinOps reporting.

Different Stakeholders Use Allocation Differently

• Finance uses allocation to support showback, chargeback, forecasting, and cost-center reporting.
• Operations uses it for budget tracking, planning, and workload management.
• Engineering uses it to separate environments, services, and product costs.
• Leadership uses it to understand which business activities drive spend.

Start Early and Stay Consistent

• Strong account and tagging strategies should be established early.
• Consistency matters more than perfect granularity.
• Strategies will evolve over time, but a stable baseline is necessary for reliable reporting.

Cloud Providers Support Both Models

• All major cloud vendors support some form of tagging or labeling.
• They also provide hierarchy-based grouping constructs such as AWS Organizations, Google Cloud folders, and Azure Management Groups.
• Some providers allow tagging at higher hierarchy levels in addition to individual resources.

Why Combined Strategies Usually Work Best

• Hierarchy-based allocation gives strong primary separation.
• Tagging adds detailed business context inside those boundaries.
• Using both reduces unallocated spend and improves reporting flexibility.

Hierarchy-First Is Usually the Better Starting Point

• If an organization must start with only one model, hierarchy-based allocation is usually safer.
• Every resource already belongs to an account, subscription, project, folder, or resource group.
• These structures are also commonly aligned to security boundaries and team ownership.
• That makes them easier to enforce than perfect tagging coverage.

Why Tag-Only Strategies Struggle

• Tagging is flexible, but coverage is rarely complete.
• DevOps teams often miss tags, especially during early cloud adoption or in fast-moving environments.
• Some resource types do not support tagging at all.
• The result is often a large pool of unallocated spend.

Tags Still Matter

• A weak tag-only strategy does not mean tagging is optional.
• Tags are still the best way to capture fine-grained details such as owner, role, product, environment, or service.
• They are most effective when layered on top of a strong hierarchy model.

Allocation Requires Discipline

• Allocation breaks down when teams are inconsistent.
• Shared accounts, incomplete metadata, and unclear ownership all lead to distorted reporting.
• The goal is not perfection, but a model that is consistent enough to support decisions with confidence.

Three core methods to add cost allocation data

1. Resource-level tags: metadata applied directly to cloud resources.
2. Accounts, projects, subscriptions, or resource groups: hierarchy data already represented in billing files.
3. Post-bill data constructs: additional logic added after billing export using analytics, external data, or custom processing.

How to Start Building a Strategy

• Involve finance, engineering, operations, and management early.
• Review any existing tagging or account structures before defining a new standard.
• Design for company-wide usefulness rather than solving only one team’s problem.

Communicate the Plan Clearly

• Allocation strategy affects multiple teams and reporting views.
• Without shared agreement, different groups will optimize for their own needs and reduce consistency. Tags will be everywhere and not consistent at all.
• Audit existing practices first, then define a standard that supports both financial and technical requirements.

Focus on the Most Important Dimensions

• The most useful financial splits are usually team, service, business unit or cost center, and organization.
• We started with businessUnit and businessApplication, added in a businessApplicationId and then later, environments.
• These dimensions support the most common reporting and accountability questions.
• Less critical tags can be recommended without being mandatory.

Keep the Initial Model Simple

• Start with three to five dimensions you genuinely need. We've done this.
• Common early examples include business unit, product, owner, and role.
• Hierarchies can be used to isolate environments such as development and production.
• Simple models are easier to adopt, govern, and improve.

Complexity Grows Quickly

• Overly granular structures become hard to understand and maintain.
• Large shared accounts with many teams inside them make later cost interpretation difficult.
• FinOps systems should be intuitive enough that teams can explain cost patterns without excessive manual analysis.

Define the Questions Before the Model

• A good allocation strategy is driven by the questions the business needs answered.

Common examples include:

1. Which business unit should be charged for this cost?
2. Which cost centers are increasing or decreasing spend?
3. What does it cost to operate a given product or service?
4. Which costs are nonproduction and safe to reduce or turn off?

Allocation Options of the Big 3 Cloud Providers

• AWS, Google Cloud, and Azure all support hierarchy-based and tag-based allocation, but their details differ.
• Limits vary by provider, including tag counts, supported characters, and whether tags automatically appear in billing exports.
• These differences matter more in multi-cloud environments where consistency becomes harder.

Azure-Specific Considerations

• Azure resources are deployed inside resource groups, which can also be tagged.
• Azure Management Groups add a higher-level hierarchy for organizing subscriptions.
• That gives Azure teams a useful combination of structure-level and resource-level allocation options.
• Azure Policy can enforce tagging standards at scale, but it does not support all resource types and can be bypassed if not configured carefully.

Comparing Accounts Versus Tags

• Accounts or subscriptions are mutually exclusive containers.
• Tags are not mutually exclusive and can represent multiple dimensions at once.
• Because of that, accounts are usually better as the primary allocation index, while tags act as the secondary layer.

Organizing Accounts and Projects into groups - common Best Practices

• Use hierarchy to separate the most important primary dimensions such as product, environment, or organizational boundary.
• Use tags to add detail inside those boundaries.
• This gives cleaner chargeback options while still supporting detailed analysis.

Why Environments Are Often Separated

• Development, staging, and production costs often need different financial treatment.
• Some spending may map to research and development, while other spending maps to cost of goods sold or operational expense.
• Separating environments at the hierarchy level makes these distinctions easier to report and govern.

Getting Started early with Tags is Critical

• Tags are not retroactive in a useful reporting sense if they are missing during the period of spend.
• Late tagging creates historical gaps in allocation and weakens later analysis.
• That is why tagging standards should be defined early and enforced consistently.

Deciding when to set your Tagging standards

• Tagging standards are easier to implement when leadership treats them as required operating practice.
• Without that support, teams often delay remediation or apply tags inconsistently.
• A tagging model with executive backing tends to produce better long-term compliance.

Picking the Right Number of Required Tags

• Requiring too many tags creates friction and lowers compliance.
• The better approach is to require only the core metadata needed for reporting and accountability.
• Additional tags can remain optional when they provide local value but are not central to FinOps outcomes.

Common High-Value Tags

• Cost center or business unit. BU
• Service or workload name. Service Line
• Resource owner or responsible team. App id?
• Friendly resource name. The name
• Environment such as development, test, staging, or production. Tip: The most mature FinOps practices use tags to connect cloud resources to other sources of information, such as configuration management databases (CMDBs). This both enables large amounts of data to be referenced and allows quicker/simpler processes of updating information once and not having to correct potentially millions of tags on cloud resources.

Use Hierarchy for the Most Important Dimensions

• Mature teams often use hierarchy for one or two of the most important allocation dimensions.
• Environment and cost center are common examples.
• Tags then carry the remaining business context that needs finer granularity.

Tag Restrictions Need Planning

• Providers differ in allowed characters, value length, and the number of tags supported.
• A tagging policy that works in one service may fail in another.
• Multi-cloud or even multi-service environments need standards that are compatible across the estate.
• RandD vs R&D vs RD vs ResearchAndDevelopment is a common example of how small differences can cause reporting fragmentation.

Note: The more thought-out a tagging standard is at the start, the less likely a future revision will be required. If you need to go back to a team and ask them to change a bunch of tags after they just finished rolling out your previous strategy, you’re not going to make any friends

Tag Hygiene Is an Operating Practice

• Tag hygiene means keeping metadata accurate, complete, and consistent.
• Differences such as prod versus production or Enterprise versus enterprise fragment reporting and reduce trust in the data.
• Automation is the most reliable way to enforce consistency.

Automation Improves Tag Quality

• Infrastructure automation tools can reduce human error and standardize tag application.
• Governance tooling can also block or remediate resources created without valid tags.
• These controls reduce unexplained spend before it accumulates.

Parent and Child Resource Strategy Matters

• Some organizations replicate tags from parent resources to child resources.
• Others rely on tagging at a higher construct such as an Azure resource group.
• The right choice depends on how reporting logic is designed and how consistently those layers are managed.

Default Allocation Can Reduce Unexplained Spend

• Some organizations assign default cost centers to accounts or other hierarchy nodes.
• Untagged resources can then inherit a fallback allocation path.
• This can be implemented either in cloud metadata itself or later in reporting logic.

Reporting on Tagging Performance

• Reporting should track how much spend is properly tagged versus untagged.
• Measuring by spend instead of raw resource count gives more practical insight.
• A realistic target is often high coverage rather than perfect coverage, especially when some services remain untaggable.

Visibility Drives Better Compliance

• Teams respond better when untagged spend is visible in shared reporting.
• Leaderboards, exception reports, and regular reviews help create accountability.
• This turns tagging from a policy document into an operating behavior.

Tag-on-Create Is the Strongest Pattern

We do this.

• The best long-term approach is to require tagging at creation time.
• Preventive controls are more effective than cleaning up large numbers of resources later.
• This reduces allocation gaps and improves historical reporting quality.

Strategic Lessons

• Combined hierarchy and tag strategies are usually the most resilient.
• Hierarchy-first approaches often provide the cleanest foundation.
• Tagging remains necessary for granular visibility.
• Simplicity, consistency, and stakeholder alignment matter more than theoretical perfection.
• Allocation strategy should be built around the questions the organization actually needs answered.

Conclusion

Good FinOps practices should start with a carefully crafted account and tagging strategy. The extra metadata created by account hierarchy and tagging plays a role in almost all downstream reporting and analytics.

To summarize:

• Account allocation strategies provide structure to resources and make costs easier to group and explain.
• Helping the organization understand the value of tags, and automating them where possible, benefits the business broadly.
• Cost visibility and accountability built from hierarchy and tagging support a leaner, more disciplined operating culture.
• Tagging and account allocation are recurring requirements throughout the optimize phase of the FinOps lifecycle.
• Formulating a cost allocation strategy early strengthens many other FinOps capabilities, especially forecasting. Additional resource:
• Spotify podcast episode on balancing hierarchy and tags in practice: https://open.spotify.com/episode/7JeqHkTN6jwSD2pFLu5I50?si=d202db1fd58749aa&nd=1&dlsi=2bbce6187bdd41b3

Glossary

Term	Definition
Allocation strategy	The combined hierarchy, metadata, and processing rules used to assign cloud spend to the right owners and business dimensions.
Business context	The ownership and organizational meaning added to billing data, such as team, product, service, environment, or cost center.
Hierarchy-based allocation	A cost allocation approach that relies on cloud-native containers such as accounts, subscriptions, projects, folders, or resource groups.
Management group	An Azure hierarchy layer above subscriptions used to organize governance and policy at scale.
Post-bill construct	Additional allocation logic added after billing export through analytics, mapping tables, or custom processing.
Resource group	An Azure container that groups related resources and can also carry metadata used for reporting and governance.
Tag-based allocation	A cost allocation approach that relies on resource metadata such as tags or labels to add business meaning to spend.
Tag hygiene	The ongoing practice of keeping tags complete, consistent, valid, and useful for reporting.
Tag-on-create	A control pattern that requires valid tags to be applied when resources are created rather than after the fact.
Untagged spend	Costs that cannot be fully attributed because required metadata is missing, incomplete, or unsupported.